As a meta comment: I would once again suggest making newtypes, rather than CoreWrapper type aliases, for each of the digest algorithms we support, possibly using a macro to write them.

This seems like a lot of unnecessary coupling through digest simply because the digest crates don't control their own types.

The type aliases are not semantically meaningful. It feels like internals leaking out.

It's also very, very confusing from a diagnostics perspective. See #1069.

It may be worth to experiment with newtype macros. I think we should still expose block-level types and provide ways to do conversion in both directions, but for most users plain newtypes should be indeed easier to understand. We also need to decide what should be done with variable size hashes. For example, I don't think we should introduce Blak2b512 newtype, instead it should be an alias for Blake2b<U512>.

Would suggest closing this for now.

instead it should be an alias for Blake2b<U512>.

@newpavlov that seems fine to me. Curious with hybrid-array if we could even make that Blake2b<512>

With hybrid-array we still have to use Blake2b<U512>.

@newpavlov you could potentially use the AssocArraySize to get U512 from a const generic usize: https://docs.rs/hybrid-array/0.2.0-rc.8/hybrid_array/trait.AssocArraySize.html

That would be Blake2b<U64> though (as in pub type Blake2b512 = Blake2b<U64> like it is today)? Or am I missing something?

Yes, I meant Blake2b<U64>.